Poster: Getting The Point(er): On the Feasibility of Attacks on Code-Pointer Integrity

Control-flow hijack attacks remain a major security problem, despite many years of research aimed at mitigating them. Code-Pointer Integrity (CPI) [2] is the first protection mechanism that systematically prevents all such attacks while keeping performance overhead low. In the upcoming S&P’15 paper, Evans et al. [1] claim that CPI can be bypassed on x86-64 and ARM architectures. This poster is a clarifying response to the claims in [1] that CPI as a whole has a security weakness. The CPI property by itself is secure as shown by a formal correctness proof [2]. Bugs or weaknesses in specific CPI implementations can lead to security weaknesses. We discuss different implementation alternatives, analyze their security guarantees and performance implications, and demonstrate that the attack presented in [1] is only effective against the simplest proof-ofconcept implementation of CPI. The presented attack cannot subvert the other implementation alternatives, e.g., the ones using hardware-enforced segmentation or software fault isolation. I. CODE-POINTER INTEGRITY Code-Pointer Integrity (CPI) [2] is a protection mechanism that prevents all control-flow hijack attacks that are caused by memory corruption errors with low performance overhead. CPI instruments C/C++ programs at compile time, enforcing precise memory safety for all direct and indirect pointers to code in a program, which ensures the above security guarantee. CPI comes with a proof of correctness outlined in [2]. CodePointer Separation (CPS) is a simplified version of CPI that provides practical protection against most control-flow hijack attacks by ensuring the integrity of direct pointers to code only. The performance overhead of our CPI implementation on SPEC2006 benchmarks is 8.4% on average, while the performance overhead of CPS is 1.9% on average. CPI achieves low performance overhead by limiting memory safety enforcement to sensitive pointers only (i.e., direct or indirect pointers to code). The key idea is to split program memory into two isolated regions: the safe region stores all sensitive pointers, and the regular region stores everything else. CPI uses static analysis to identify program instructions that may access the safe region, and instruments them with memory safety checks. CPI employs instruction-level isolation in order to prevent all other instructions from accessing the safe region, even if hijacked by the attacker. In order to avoid changing the memory layout of the regular region, CPI reserves the locations normally occupied by sensitive pointers in the regular region and, in the safe region, it maintains a map from the addresses of these reserved locations to pointer values and corresponding metadata required for memory safety checks. An implementation of CPI or CPS consists of (i) a static analysis pass that splits all memory accesses in a program into those that may access sensitive pointers and those that cannot, (ii) an instrumentation pass that instruments all accesses that might access sensitive pointers to use the safe region and inserts runtime checks that enforce memory safety of these accesses, and (iii) an instruction-level isolation mechanism that prevents all memory accesses that are not instrumented with memory safety checks from ever accessing the safe region, even if a memory access is compromised by an attacker. This poster focuses on the third step, as do Evans et al. [1]. We implemented and presented in [2] multiple mechanisms that efficiently enforce instruction-level isolation using either hardware-enforced segmentation, software fault isolation, or randomization and information hiding. The security guarantees and performance implications of these mechanisms are summarized in Table I, we discuss them in detail below. We focus on design choices behind each mechanism and ignore potential non-design bugs in the prototypes we released. The attack in [1] focuses on one of these mechanisms, namely the one based on information hiding, and it is only effective against its simplest proof-of-concept implementation. A. Hardware-Enforced Segmentation Based Implementation On architectures that support hardware-enforced segmentation, CPI uses this feature directly to enforce instruction-level isolation. In such implementations, CPI dedicates a segment register to point to the safe memory region, and it enforces, at compile time, that only instructions instrumented with memory safety checks use this segment register. CPI configures all other segment registers, which are used by non-instrumented instructions, to prevent all accesses to the safe region through these segment registers on the hardware level. Hardware-enforced segmentation is supported on x86-32 CPUs, but also on some x86-64 CPUs (see the Long Mode Segment Limit Enable flag), which demonstrates that adding segmentation to x86-64 CPUs is feasible, provided the techniques that could benefit from it prove to be indeed valuable. This implementation of CPI is precise and imposes zero performance overhead on instructions that do not access sensitive pointers. It is not vulnerable to the attack in [1]. B. Software Fault Isolation Based Implementation On architectures where hardware-enforced segmentation is not available (e.g., ARM and most of the x86-64 CPUs), the instruction-level isolation can be enforced using lightweight